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In principle, formal methods offer many advantages for aerospace software development: they can help 
to achieve ultra-high reliability, and they can be used to provide evidence of the reliability claims which 
can then be subjected to external scrutiny. However, despite years of research and many advances in the 
underlying formalisms of specification, semantics, and logic, formal methods are not much used in practice. 
In our opinion this is related to three major shortcomings. First, the application of formal methods is still 
expensive because they are labor- and knowledge-intensive. Second, they are difficult to scale up to complex 
systems because they are based on deep mathematical insights about the behavior of the systems (i.e., they 
rely on the “heroic proof”). Third, the proofs can be difficult to interpret, and typically stand in isolation 
from the original code. 

In this paper, we describe a toofdbrTormally demonstrating safety- relevant aspects of aerospace software, 
which largely circumvents these problems. We focus on safety properties because it has been observed 1 
that safety violations such as out-of-bounds memory accesses or use of uninitialized variables constitute the 
majority of the errors found in the aerospace domain. In our approach, safety means that the program will 
not violate a set of rules that can range for the simple memory access rules to high-level flight rules. These 
different safety properties are formalized as different safety 'policies in Hoare logic, which are then used by a 
verification condition generator along with the code and logical annotations in order to derive formal safety 
conditions; these are then proven using an automated theorem prover. Our certification system is currently 
integrated into a model-based code generation toolset that generates the annotations together with the code. 
However, this automated formal certification technology is not exclusively constrained to our code generator 
and could, in principle, also be integrated with other code generators such as RealTime Workshop or even 
applied to legacy code. 

Our approach circumvents the historical problems with formal methods by increasing the degree of 
automation on all levels. The restriction to safety policies (as opposed to arbitrary functional behavior) 
results in simpler proof problems that can generally be solved by fully automatic theorem provers. 2 An 
automated linking mechanism between the safety conditions and the code provides some of the traceability 
mandated by process standards such as DO-178B. 3 An automated explanation mechanism uses semantic 
markup added by the verification condition generator to produce natural- language explanations of the safety 
conditions and thus supports their interpretation in relation to the code. Figure 1 shows an automatically 
generated certification browser that lets users inspect the (generated) code along with the safety conditions 
(including textual explanations), and uses hyperlinks to automate tracing between the two levels. Here, 
the explanations reflect the logical structure of the safety obligation but the mechanism can in principle be 
customized using different sets of domain concepts. The interface also provides some limited control over 
the certification process itself. 

Our long-term goal is a seamless integration of certification, code generation, and manual coding that 
results in a “certified pipeline” in which specifications are automatically transformed into . executable code, 

together with the supporting artifacts necessary for adueving and demonstr a ting the h i g h levels .of. assurance . 
needed in the aerospace domain. 
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Figure 1. Certification browser 
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